// std #include #include #include #include #include #include <type_traits>

chrono is NOT allowed since it is not freestanding

ask @SekaiArendelle

btw, you cannot assume you can use threads in newlib. newlib simply does NOT provide threads. The compiler will make weird decisions.

btw, you cannot assume you can use threads in newlib. newlib simply does NOT provide threads. The compiler will make weird decisions.

no thread, only provided this_thread::sleep_for sleep_until and yield, the newlib provide a fake function there

// std #include #include #include #include #include #include <type_traits>
chrono is NOT allowed since it is not freestanding

ask @SekaiArendelle

what can i say

// std #include #include #include #include #include #include <type_traits>
chrono is NOT allowed since it is not freestanding

ask @SekaiArendelle

what can i say

the solution is make them protected by macro __has_include

@trcrsired add contidional include

为什么要在那些文件里加

#if __has_include()
#include
#endif

#include
#include
#include

完全就是瞎搞。而且谁规定你光has_include就能include了？禁止在全库所有的位置加include，懂？

include

让 @SekaiArendelle 改了，这个他一开始就这么搞的

你让他把这坨清理了

你让他把这坨清理了

你让ai搞

你让他把这坨清理了

你让ai搞

ok，等几天

also just f chrono. It sucks. I do not want 20ms unit junk to be in my library. There is a reason why this library uses unix_timestamp, iso8601_timestamp etc.

DO NOT USE chrono header.

Get the modern C++ junk out of my library. Long live C with Concepts. No more C with Classes or Modern C++.

removed @trcrsired

inline ::std::atomic<wasi_thread_id> next_thread_id{1u};

inline thread_local wasi_thread_id current_thread_id{};

This is also UNACCEPTABLE. You cannot have hello world to emit globals. Totally violates zero overhead principle

please do not randomly add junk. or i will close this PR.

Also, how is this PR "fix newlib"? It is a terrible title and has nothing to do with what it actually does.

please do not randomly add junk. or i will close this PR.

Also, how is this PR "fix newlib"? It is a terrible title and has nothing to do with what it actually does.

it fix newlib compilation when using this_thread.

and fix emscripten target

all the commits are fix fix fix. This is bad

all the commits are fix fix fix. This is bad

when you squash it, the all commit message will merge into once

why do you try to implement ::std::atomic for wasi? Didn't wasi libc provide threads enabled version? We really should NOT duplicate libc functionalities.

Also, i have a strong opposition to include atomic header since the standard library does not implement it correctly as freestanding

why do you try to implement ::std::atomic for wasi? Didn't wasi libc provide threads enabled version? We really should NOT duplicate libc functionalities.

Also, i have a strong opposition to include atomic header since the standard library does not implement it correctly as freestanding

wasm-thread proposal supported atomic

if you want a feature, implement it yourself. and i just disabled the wasi-thread.

Although you prefer to use __builtin functions for atomics, the basic
header file that provides the atomic functionality is definitely
available. Some C++20‑era features might not be provided, but they’re not
used here.

Although you prefer to use __builtin functions for atomics, the basic header file that provides the atomic functionality is definitely available. Some C++20‑era features might not be provided, but they’re not used here.

that is simply untrue. libc++'s atomic header relies on hosted features. The entire atomic is a shit show

that is simply untrue. libc++'s atomic header relies on hosted features. The entire atomic is a shit show

I’ve already disabled it. Whether you prefer to merge or not, you don’t need the atomic or builtin functions. How do you generate the WASM atomic instructions? Feel free to try it yourself.

When a simple problem drags on for too long, developers are more likely to stop contributing to the trunk.

After the merge, they threatened to change the license and invalidate earlier code. I won’t continue to contribute to such disrespectful projects.

that is simply untrue. libc++'s atomic header relies on hosted features. The entire atomic is a shit show

I’ve already disabled it. Whether you prefer to merge or not, you don’t need the atomic or builtin functions. How do you generate the WASM atomic instructions? Feel free to try it yourself.

The problem is that atomic header itself uses hosted features from libc despite C++ standard marks its as freestanding. That just breaks things. Even the C++ standard admitted that.

For example:
https://en.cppreference.com/w/cpp/freestanding.html
↑ Support for always lock-free integral atomic types and presence of type aliases std::atomic_signed_lock_free and std::atomic_unsigned_lock_free are implementation-defined in a freestanding implementation.(since C++20)

In fact, libc++ is still bugged and i tried to submit patch for freestanding and it never got merged.
trcrsired/llvm-project@f8925ca

https://youtu.be/DorYSHu4Sjk?si=xG99n2QaGeG3jBsv

Also, I still do not get why you cannot simply just call into apis in libc. Also when did the library try to support emscripten?

There was a reason why i never added threads into the library because i do not think the APIs would get designed correctly, particularly i really really hate C++ standard threading apis.

that is simply untrue. libc++'s atomic header relies on hosted features. The entire atomic is a shit show

I’ve already disabled it. Whether you prefer to merge or not, you don’t need the atomic or builtin functions. How do you generate the WASM atomic instructions? Feel free to try it yourself.

The problem is that atomic header itself uses hosted features from libc despite C++ standard marks its as freestanding. That just breaks things. Even the C++ standard admitted that.

For example: https://en.cppreference.com/w/cpp/freestanding.html ↑ Support for always lock-free integral atomic types and presence of type aliases std::atomic_signed_lock_free and std::atomic_unsigned_lock_free are implementation-defined in a freestanding implementation.(since C++20)

In fact, libc++ is still bugged and i tried to submit patch for freestanding and it never got merged.

https://youtu.be/DorYSHu4Sjk?si=xG99n2QaGeG3jBsv

Also, I still do not get why you cannot simply just call into apis in libc. Also when did the library try to support emscripten?

There was a reason why i never added threads into the library because i do not think the APIs would get designed correctly, particularly i really really hate C++ standard threading apis.

The underlying implementation relies on __c11_atomic_store, but this is emitted as assembly even with -O0—it’s a built‑in that comes with Clang but isn’t present in GCC.

When a simple problem drags on for too long, developers are more likely to stop contributing to the trunk.

1. It is not a simple problem.
2. You never discussed with me on how the APIs would be designed for threading. In fact even the compiler itself makes weird decisions on how things like thread model works.

clang++ -v
clang version 23.0.0git ([email protected]:trcrsired/llvm-project.git 070b9ef41e472b231e4b5129a50960de1c2b38a5)
Target: aarch64-unknown-windows-gnu
Thread model: posix
InstalledDir: C:/Users/unlvs/toolchains/llvm/aarch64-windows-gnu/llvm/bin

There is a reason why compiler says the thread model here is "posix" which means the compiler just does weird assumptions on threads and atomic things In general. Just like compilers do assumptions on your triplet. Just implementing things like this_thread without compiler helps cannot be correct.

For freestanding, it often simply does not have threads. The thread model GCC gives would be "single". You just should not use threads at all.

3. chrono, charconv are other terrible headers.
   https://en.cppreference.com/w/cpp/chrono.html

For example tzdb
(C++20)

Tell me how do you implement tzdb in C++? You just cannot. It has to rely on C library or 3rd party libraries under the hood for metadata.
Also i do not like the unit APIs. sleep(3s) and sleep(3000ms) does not match the POSIX struct timespec apis and it would also duplicate for every unit. Not mentioning overflow issues. The chrono is just a terrible header.

that is simply untrue. libc++'s atomic header relies on hosted features. The entire atomic is a shit show

I’ve already disabled it. Whether you prefer to merge or not, you don’t need the atomic or builtin functions. How do you generate the WASM atomic instructions? Feel free to try it yourself.

The problem is that atomic header itself uses hosted features from libc despite C++ standard marks its as freestanding. That just breaks things. Even the C++ standard admitted that.
For example: https://en.cppreference.com/w/cpp/freestanding.html ↑ Support for always lock-free integral atomic types and presence of type aliases std::atomic_signed_lock_free and std::atomic_unsigned_lock_free are implementation-defined in a freestanding implementation.(since C++20)
In fact, libc++ is still bugged and i tried to submit patch for freestanding and it never got merged.
https://youtu.be/DorYSHu4Sjk?si=xG99n2QaGeG3jBsv
Also, I still do not get why you cannot simply just call into apis in libc. Also when did the library try to support emscripten?
There was a reason why i never added threads into the library because i do not think the APIs would get designed correctly, particularly i really really hate C++ standard threading apis.

The underlying implementation relies on __c11_atomic_store, but this is emitted as assembly even with -O0—it’s a built‑in that comes with Clang but isn’t present in GCC.

That does not mean the atomic header won't do random weird things compared to builtins. The problem is that the toolchain itself would very likely not providing the header of atomic correctly. Just like memory header simply did not exist for GCC before despite std::addressof relies on compiler magic.

1. It is not a simple problem.
2. You never discussed with me on how the APIs would be designed for threading. In fact even the compiler itself makes weird decisions on how things like thread model works.

clang++ -v
clang version 23.0.0git ([email protected]:trcrsired/llvm-project.git 070b9ef41e472b231e4b5129a50960de1c2b38a5)
Target: aarch64-unknown-windows-gnu
Thread model: posix
InstalledDir: C:/Users/unlvs/toolchains/llvm/aarch64-windows-gnu/llvm/bin

There is a reason why compiler says the thread model here is "posix" which means the compiler just does weird assumptions on threads and atomic things In general. Just like compilers do assumptions on your triplet. Just implementing things like this_thread without compiler helps cannot be correct.

For freestanding, it often simply does not have threads. The thread model GCC gives would be "single". You just should not use threads at all.

3. chrono, charconv are other terrible headers.
   https://en.cppreference.com/w/cpp/chrono.html

For example tzdb (C++20)

Tell me how do you implement tzdb in C++? You just cannot. It has to rely on C library or 3rd party libraries under the hood for metadata. Also i do not like the unit APIs. sleep(3s) and sleep(3000ms) does not match the POSIX struct timespec apis and it would also duplicate for every unit. Not mentioning overflow issues. The chrono is just a terrible header.

chrono was provided by AR, not something I originally implemented, and I have already removed it.

chrono was provided by AR, not something I originally implemented, and I have already removed it.

Also the basic_timestamp things may need some tweaks or even removed completely. It should be removed and replaced with something which is identical to struct timespec in POSIX but more portable. That was a mistake by me. I thought to use as many digits as possible for subseconds, however in reality, no APIs have yet done that. They all at most use nanoseconds. While it makes initializing the api much harder. So a lot of things need to be changed first before adding threading because it is you who wants the sleep api.

You should first have a discussion with me on QQ group on how APIs should be designed before adding a PR. Just randomly adding a PR to add a whole new thing without the author's consent and then blame me for not merging your code is not constructive.

Also the basic_timestamp things may need some tweaks or even removed completely. It should be removed and replaced with something which is identical to struct timespec in POSIX but more portable. That was a mistake by me. I thought to use as many digits as possible for subseconds, however in reality, no APIs have yet done that. They all at most use nanoseconds. While it makes initializing the api much harder. So a lot of things need to be changed first before adding threading because it is you who wants the sleep api.

You should first have a discussion with me on QQ group on how APIs should be designed before adding a PR. Just randomly adding a PR to add a whole new thing without the author's consent and then blame me for not merging your code is not constructive.

你把ar拉进来一起聊，thread他和我搞的

Also the license thing. Tivoized hardware is not something we can and should support since there is no way to test it. They do not want us to run it. The security concern is very very real.

https://www.androidheadlines.com/2025/12/nearly-a-billion-active-android-devices-are-security-targets-due-to-outdated-software.html

Also the basic_timestamp things may need some tweaks or even removed completely. It should be removed and replaced with something which is identical to struct timespec in POSIX but more portable. That was a mistake by me. I thought to use as many digits as possible for subseconds, however in reality, no APIs have yet done that. They all at most use nanoseconds. While it makes initializing the api much harder. So a lot of things need to be changed first before adding threading because it is you who wants the sleep api.
You should first have a discussion with me on QQ group on how APIs should be designed before adding a PR. Just randomly adding a PR to add a whole new thing without the author's consent and then blame me for not merging your code is not constructive.

你把ar拉进来一起聊，thread他和我搞的

你们两个自己退的fast_io群。在小仙女群讨论也行